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A METHOD OF ENABLING AN APPLICATION TO ACCESS FILES 
STORED ON A REMOVABLE STORAGE MEDIUM 

BACKGROUND OF THE INVENTION 



1 . Field of the Invention 



This invention relates to a method of enabling an application, running on an operating 
system, to access files stored on a removable storage medium; the operating system and 
the storage medium use incompatible directory hierarchies. 

2. Description of the Prior Art 

SymbianOS™ applications assume a directory structure that has been defined by 
Symbian Limited to include a standard set of directories starting from the root of a 
drive. Unfortunately, this is not compatible with the Memory Stick™ standard defined 
by Sony Corporation for its removable memory drives. More specifically, SymbianOS 
defines a directory structure on removable drives which contains a number of standard 
locations, the most basic being: 

\ 

\System 

\System\Apps 

\System\Libs 

\System\Data 

\Documents 

Only some of these may exist. Some may contain further subdirectories - for example 
installed applications are placed in a directory below \System\Apps named after the 
application, and there are various other standard directories. 

By contrast, Memory Stick defines a hierarchy like this: 

\DCIM 

\HiFi 

\MSXXX\... 
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\MSYYY\... 

Importantly, the Memory Stick standard says that only the defined root subdirectories may be 
placed in the root All device-specific data that is not part of the standard must be placed 
5 inside one of the MSXXX/MSYYY subdirectories, where the "XXX" "YYY" is a 
sequence of characters registered with Sony and unique to that device or manufacturer. 

Clearly this is not compatible because SymbianOS defines a directory hierarchy starting 
at the root but the Memory Stick standard does not allow non-standard directories in 
the root To comply with the Memory Stick standard, the SymbianOS hierarchy would 
10 have to be inside an MSXXX subdirectory. But all SymbianOS code* (including most, if 
not all, third-party code) has been written assuming the root-based directory structure 
and cannot easily be modified to use one compliant with Memory Stick. 

Changing every SymbianOS application to comply with the Memory Stick hierarchy is a 
15 large effort that it would be preferable to avoid. Even if this were done, it would be 
difficult to verify that there are no "rogue" cases which could create an illegal root 
directory. 

European Patent Application No. EP11 22647 A2 filed by Hewlett-Packard Company 
20 entided "A method and apparatus for virtualizing file access operations and other I/O 
operations" describes a method of enabling a media hierarchy as seen by applications to 
be mapped to a different file system. It does not however relate to making 
incompatible media directory hierarchies, which cannot otherwise be modified, 
intemperate. This interoperability is the basis of the present invention. 

25 
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In a first aspect of the invention, a method of enabling an application, running on an 
operating system with a first directory hierarchy, to access files stored on a removable 
5 storage medium using a second directory hierarchy that is incompatible with the first 
directory hierarchy, comprises the following steps: 

(a) the application sends a file request with a path that conforms to the first 
directory hierarchy, and 

(b) the path in the file request is translated to an equivalent path that 
10 conforms to the second directory hierarchy. 

The effect is to map or translate all paths in application- file requests to the equivalent 
path needed by the storage medium. Hence, a path that conforms to the SymbianOS 
standard can be transparendy mapped to a Memory Stick path: it is 'transparent' in that 

15 the application has no awareness of the translation that occurs: it simply sees the 
standard hierarchy mandated by the OS. The translation is also transparent to the file 
server component of the operating system. Prior art systems do not address the problem 
of enabling an application running on an OS with a specific directory hierarchy to access 
files held on a removable drive that uses a different and incompatible directory 

20 hierarchy. Instead, whilst they may deal with translating file request from a virtual 
address to a physical one, both addresses must always conform to the same' directory 
hierarchy. 

A second aspect of the invention is a portable computing device programmed to enable 
25 an application running on it to access files stored on a removable storage medium, in 
which the application sends a file request with a path that conforms to a directory 
hierarchy used by the device operating system, the device being further programmed to 
translate the path in the file request to an equivalent path that conforms to a second 
directory hierarchy used by the storage medium, the second directory hierarchy being 
30 incompatible with the first. 
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The present invention will be described with reference to an implementation for 
.Symbian OS, the operating system for smartphones and other wireless information 
5 devices. This implementation enables applications written to run on SymbianOS and 
using the file hierarchy mandated by SymbianOS to use the Memory Stick storage 
medium, even though Memory Stick uses an entirely different directory hierarchy. 

10 Root remapping 

*. 

The requirement is that applications should see a drive (say drive D:) which appears to 
be a standard Symbian hierarchy but which actually is located somewhere off the root 
on the Memory Stick. In addition, applications should not directly see the real root of 
15 the Memory Stick but that the root should still be available to applications by some 
method. 

Notionally, all paths that refer to drive D: are, automatically prefixed by an extra path, 
called the root offset. This root offset is equal to the location on the Memory Stick at 
which the data on the D: drive actually exists. This happens completely transparendy 
20 and applications are not aware of the change. 

Note that the translation does not necessarily concatenate two strings to form a third 
string, but this is the effective behaviour. 

For example, consider that the root directory registered with Sony is MSSymbian. We 
want the Symbian hierarchy on drive D: to actually be placed inside the MSSymbian 
25 directory. Notionally, the string "\MSSymbian" is added to the start of all paths 
accessing drive D:. 

So for example, take a Memory Stick that has this directory structure: 
\ 

\DCIM 
30 \HiFi 

\MSSymbian 

\MSSymbian\System 

\MSSymbian\Documents 

If an application requests a directory listing of !I D:\* !I , the file sysuv^ w*** 
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convert this to ,! D:\MSSymbian\*" and give the result: 

\System • 
\Documents 

which is the standard Symbian layout as expected by the application. Note that to the 
5 application this appears to be the root of the . drive but actually it is not 

If the application were now to create a directory "\Documents\MyFiles", this would be 
translated again by the file system to "\MSSymbian\Documents\MyFiles". 

Conceptually the string "\MSSymbian" is prefixed to all strings passed into the file 
system. In practice this might be implemented in a different way, for example starting all 
10 name searches from the MSSymbian directory instead of the root would be more 
efficient, but the effect is the same. 

This therefore allows applications to continue using the Symbian hierarchy but enforces 
compliance with the Memory Stick standard. 

15 Accessing the root — the magic directory 

The root offset method described above hides the root completely. Some applications 
may be Memory Stick aware (that is, they understand the Memory Stick structure and 
will want to access some of the standard interchange directories defined in the 
20 standard). To allow access to the root, a "magic" directory is provided, 
\System\MSROOT. This is really the reverse of the root offset because it is notionally 
stripped from all paths passed to the file system. 

So for example if an application wants to access the Memory Stick \DCIM directory 
(for images), it would use the path "\System\MSROOT\DCIM". The file system would 
25 then notionally strip (i.e. skip) the magic prefix "\System\MSROOT" from this to leave 
"\DCIM", the intended target directory. 

The reason for providing access to the root in this manner rather than allowing 
applications to view the real Memory Stick hierarchy is to enforce cc 
hierarchy. If the full Memory Stick root were visible - on anoth 
30 example, applications could accidentally violate the Memory Stic 
creating files and directories on this drive. 
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Overlaying an existing file or directory 

The magic directory does not actually exist on the Memory Stick, so if the Memory Stick 
held a real file or directory \MSSymbian\System\MSROOT, the magic directory would 
• hide it. 

The presence of a real file/directory called \System\MSROOT does not interfere with 
the operation of the "magic" directory because it is handled entirely within the file and 
the translation occurs without reference to the content on the Memory Stick. 

However, the user may want to access this file/directory — this is still possible in two 
•ways: 

a) Use the "partial circular reference 11 : 
\System\MSROOT\MSSymbian\System\MSROOT 
which will be map to: 
\MSSymbian\System\MSROOT 

on the Memory Stick, which is the user's file/directory. This is an inconvenient 
implementation because it requires one case of circular references to be allowed. See the 
description of circular references below. 

b) The preferred method is to take advantage of the fact that on the FAT file system 
used on Memory Stick the; file name is not case-sensitive. If we define that the magic 
directory is case sensitive, then using \System\MSROOT will invoke the magic re- 
mapping into the root, but any other case, such as \System\msroot, \System\MSRoot, 
\system\MSROOT will give the true file/ directory that exists on the Memory Stick. 

Circular references 

In theory it would be possible to make the translation repeatedly and create a circular 
reference. For example, the path: 

\System\MSROOT\MSSymbian\System\MSROOT\MSSymbian\fred 

is identical to 

\fred 

The problems to allowing this are: 
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1. It allows files to have aliases - that is, one file can be accessed by more than one 
name. This can provide serious problems to file sharing and locking semantics in 
upper layers which may see this as different files. 

2. It can potentially lead to infinite loops - for example if a file browser application 
5 followed a circular reference forever. 

To prevent this, the conversion is only done once so circular references cannot occur. 
For example the path "\System\MSROOT\MSSymbian\System\MSROOT H appears to 
be a circular reference, but in fact the file system will only translate the first occurrence 
of the magic path, to leave "\MSSymbian\System\MSROOT" which either doesn't 
10 exist or will refer to an existing file or directory on the Memory Stick. 

Applications must be prevented from circularly referencing the Symbian root, 
\MSSymbian, via the \System\MSROOT magic directory. For' example the files 
\fred.txt and \System\MSROOT\MSSymbian\fred.txt are identical but can cause the 
problems described above. Therefore access to the MSSymbian directory is always 
15 rejected except by means of the root offset mechanism. Thus in this example an attempt 
to access \System\MSROOT\MSSymbian\fred.txt would return an error indicating 
that access is denied, or equally effectively that the file could not be found. 

Directory Listings 

20 

Generally directory listings proceed as normal with the translation resulting in the true 
directory on the Memory Stick, which is returned verbatim. All directory contents as 
seen by the application are identical to the directory contents on the Memory Stick 
except for the two special cases of \System\*, which contains the MS ROOT magic 
25 directory and \System\MSROOT\* which is the root of the Memory Stick and contains 
the MSSymbian directory which is the root as seen by applications. These two cases 
need to be handled specially. 

To avoid applications that Search drives from accidentally straying into the magic 

\System\MSROOT directory and being able to accidentally create fi 1 — ; ~ * u - * 

30 do not comply with the Memory Stick standard, the magic directory 
a listing of the \System directory content. An application that is M 
would know that it should use \System\MSROOT to access the rool 
are not aware of this will not find it in a directory listing so will not 
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the enforced SymbianOS directory structure. 

Simlarly, as described above circular access to the contents of MSSymbian via the magic 
directory must be prevented to avoid aliases. For consistency the best implementation 
would be to hide MSSymbian from a listing of the Memory Stick root and to return a 
5 "not found" error to any attempt by an application to use a path starting with 
\System\MSROOT\MSSymbian. 

(Note: the fact the an application must know of the presence of the MSROOT directory 
does not contradict the intention of the present method, since the application must also 
know how to deal with Memory Stick content and is therefore not 9. "standard" 
10 Symbian application which is unaware of Memory Sticks) 

Emulating standard directories — ghosting 

On6 further extension is to provide non-existing "ghost" directories so that applications 
15 that are not specifically Memory Stick aware can still access files from the special 
Memory Stick directories. Take as an example a picture viewing application that 
normally stores its files in 

\Documents\Pictures\... 

with a number of subdirectories below this which can be named by the user, for 
20 example "My Snaps", "Holiday", etc. 

The file system can provide another "magic" directory but this time it maps one of the 
root directories into a directory within the Symbian hierarchy — a ghost of the root 
directory. 

So for the example picture viewer, we could create a new ghost directory 
25 \Documents\Pictures\MemoryStick that actually maps to \DCIM in the Memory Stick 
root. The file system in this case is effectively substituting the ghost directory name with 
the real one. 

Thus if the application performs a directory listing of its Pictures dirertnnr it will r^p 

My Snaps 

30 Holiday 

MemoryStick 
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and will then show "MemoryStick" as a possible place to find pictures to view. A 
directory listing of \Documents\Pictures\MemoryStick\* will effectively be converted 
to \DCIM\* by the file system and will return the content of the Memory Stick DOM 
root directory. The picture viewer can then open any of the files and the same 
5 substitution will be done enabling the application to access files from a location it 
expects while they are actually somewhere else on the Memory Stick. 



Mapping without string concatenation or manipulation 

10 In the simplest implementation of the operations described above, the path provided by 
the application is modified by either stripping, adding or modifying a section of path. 
The result path is then used to perform a directory lookup. 

For example, the root offset can be implemented by concatenating the root offset with 
15 the original application path to create a resulting combined path. 

This is simple but inefficient and a better implementation is to alter the point in the file 
system at which a directory lookup starts 

20 Consider how a lookup is performed. Take a media with this content: 

\ 

\Documents 

\accounts.doc 
25 \info.doc 
\Pictures 

\Holiday 

\landscape.jpg 
\tree.jpg 

30 

An application then requests to open the file \Pictures\Holiday\lar 

essentially a recursive operation, where each component of the ] 

traversing down the directory hierarchy. So step one is to search for 

in the root directory. Once found, we move along one step and s J 



WO 2004/114117 PCT/GB2004/002711 

10 

"Holiday" in Pictures, and move along once more to find an entry "landscape.jpg" in 
Holiday. 

Now consider that the hierarchy is on a Memory Stick like this: 
5 \ 

\MSSymbian 

\Documents 

\accounts.doc 
\info.doc 
10 \Pictures 

\Holiday 

\landscape.jpg 
\tree.jpg 

15 In the simple string manipulation version the application path 
\Pictures\Holiday\landscape.jpg is converted to: 

\MSSymbian\Pictures\Holiday\landscape.jpg and the search proceeds as described 
starting with a search for "MSSymbian" in the root. 

20 However the string manipulation and the initial search in the root are wasted effort and 
time. It is unnecessary to perform the search in the root as all entries are known to be 
inside the MSSymbian subdirectory. Therefore a more efficient implementation would 
be to leave the application path unmodified but start the search from MSSymbian. So 
the search steps would start with a search for entry "Pictures" in MSSymbian and 

25 proceed to "landscape.jpg" in Holiday. 

The magic directory redirecting to the root can be handled by identifying the magic 
token in the . path and skipping it, then starting the search from the root. For example, 
the application passes \System\MSROOT\DCIM, and the ' magic token 
30 "\System\MSROOT" is recognized and skipped. The search begin* witVi flnrlino- *n 
entry "DCIM" in the root. 

The case of ghost directories is more complex because the redirectioi 
anywhere within the path and so this is probably more conveniendy 
string substitution. 



